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Abstract 


Features and operation of FlexNet 


packet networking software are 
discussed. Details of the software 
architecture, RMNC and MS-DOS 


hardware platforms, applications, user 
interface, adaptive parameters, and 
routing techniques are presented. 


Introduction 


FlexNet is a flexible, modular and 
user-friendly software program for 
packet radio networking. First conceived 
in 1987, the software has undergone 
numerous changes and improvements 
since then, and is presently (July 1995) 
at version 3.3. The most notable 
features of FlexNet are: 


Autorouter 


Automatically routes all connect 
requests with minimal input required 
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of the user. 
Adaptive Parameters 

All network parameters (except 
TXDelay) are automatically set by the 
software and adapt to changing channel 
conditions. 
Hop-to-hop Acknowledge 

Each packet is ack'd directly by its 
neighbor, improving data transport 
reliability. 
Command Interpreter 

The software interacts directly with 
the user and has numerous internal 
applications providing detailed data 
concerning the configuration and status 
of the node. 
Remote Controllability 

The node is completely 
remote-controllable, also allowing for 
remote tracing of a QSO with several 
filters. 
Modular and Portable Architecture 

Over 95 percent is written in C, 
allowing wide portability across 
platforms. 
DAMA 

Master and slave implemented. All 
channels may be master or slave, or 
mixed as desired. 


FlexNet is presently the most widely 
used packet radio networking software in 
Germany, with over 500 installations. 
Due to German amateur radio 
regulations, each unattended station 
(node) must receive special permission 
to operate and must use tightly 
coordinated dedicated point-to-point 
links. Despite creating problems and red 
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tape, these limitations have forced the 
creation of a very high-quality network 
where round-trip response times over 
hundreds of kilometers and tens of node 
sites are typically only a few seconds. 
Although FlexNet is primarily used for 
networking, the PC version can also be 
used by users by simply eliminating the 
Node module. PC/FlexNet is thus a 
flexible yet powerful replacement for 
permanent TNC emulations (such as 
TFPCX). It is extremely simple to set up 
since there are no hassles with 
parameters. FlexNet software is a 
copyrighted product of Gunter Jost 
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DK7WJ, who retains all rights. The 
software may be freely copied, 
distributed, and used for non-commercial 
Amateur Radio purposes. 


Hardware 


FlexNet is presently ported to two 
hardware platforms: The Rhein-Main 
Net Controller (RMNC) system and the 
Intel 80x86 processor running MS-DOS. 
The RMNC platform is a 6809-based 
system using a Z8530 SCC. Each 
channel control card (one for each 
radio/data channel) is on a standard 
Eurocard and is plugged into a standard 
card cage with backplane bus. One 
master card can control up to 15 slave 
cards. Developed by the Frankfurt 
(Rhein-Main) Packet Radio Group, the 
RMNC remains the preferred platform 
for FlexNet because of its low cost and 
high performance. The software resides 
ona single EPROM. 

The MS-DOS version has existed 
since 1990, but was not distributed, as it 
was used primarily as a test and 
development platform. In 1994, 
development of a stable version for 
MS-DOS was begun in earnest. FlexNet 
runs problem-free in an XT-class system, 
although faster processors are preferred. 
A number of different channel drivers 
exist, allowing for some flexibility in I/O 
hardware. The choice of MS-DOS was 
based primarily upon the large installed 
base. Admittedly, a better choice would 
be Linux, and in fact the task of porting 
FlexNet over is already being worked 
upon. 


Architecture 


In 1994, a discussion between the 
present FlexNet author (DK7WJ) and 
BayCom author Flori Radlherr 
DL8MBT yielded a new concept for 
FlexNet: Modularity. The major portions 
of the software were developed as 
separate modules, the most important 
being the channel drivers and 
applications. These modules can be used 
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in combinations as desired, on either 
hardware platform, creating a very 
flexible system and allowing a larger 
number of authors to contribute talent. In 
the near future, a "developer's kit" will 
be available, further easing module 
development. 


A number of driver modules presently 
exist: 


USCC 

Driver for all BayCom SCC cards. 
The card type is automatically detected. 
SER12 

Driver for the serial BayCom AFSK 
modem. 
KISS 

Driver for connection to a 
computer. This driver should not be 
used with a TNC, as the channel timing 
is not as precise as it should be, 
especially in the half-duplex mode. 
FIFO UARTs are supported, allowing 
data rates up to 115,200 baud on a 
286/16. 
6PACK 

Driver for TNCs. 6PACK is a new 
protocol which overcomes timing 
problems with KISS and TNCs. This 
protocol is able to control up to 8 TNCs 
in a ring (without tokens!), however the 
data rate on the RS-232 side should be 
greater than the sum of the RF baud 
rates. Beta-testing is currently 
underway, involves replacing the TNC's 
EPROM. 


PAR9I6 

Driver for the parallel version of 
the BayCom 9600 baud 
G3RUH-compatible modem 
IPXN 


Driver for Novell-IPX networks. 
Those that already have such a network 
running can link PCs using FlexNet. 
Traffic runs in the local net segment as 
broadcasts and each FlexNet station 
monitors the net traffic. 

IPXPD 

The same as IPXN, except that the 
packet driver is replaced with the IPX 
protocol itself. To be compatible with an 
IPXN system on Ethernet, only used 
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when a Novell installation is not 
available. 
IPPD 

AX/IP, a provision of IP to allow 
point-to-point connections over 
Ethernet. ARP is rudimentarily 


implemented. Not a solution for an 
internet link, but functional. Eventually 
to be integrated into a TCP/IP module. 
VANESSA 

Driver for the VANESSA channel 
card. This card from the Swiss SEPRAN 
group can control 2 RF channels and has 
its own processor, significantly reducing 
the PCs workload. 


Other drivers being developed include 
those for TMC320C25 DSP systems as 
well as Sound Blaster cards. 


Applications 


The FlexNet system supports a number 
of applications, primarily for the purpose 
of providing users and Sysops with 
information about the network or a node. 
These applications are mentioned in 
"User Interface" below. Due to the 
modular design of FlexNet, 
implementing new applications is 
relatively easy, and can be written by 
anyone having sufficient programming 
experience. Three unique applications 
deserve special mention: 


TFEMU 

Hostmode emulation. PC/FlexNet 
can be used with this application as a 
driver for various hostmode programs, 
such as BBS, DXCluster, terminal 
programs, etc. 
ETHEREMU 

FlexNet can be used with this 
application to emulate an _ ethernet 
packet driver, allowing for example 
NCSA-Telnet or Winsocket applications 
to be worked via AX.25 Datagrams or 
Virtual Circuits. 
RDOS 

Remote DOS interface for service. 
This application allows full remote 
control of MS-DOS, even such local 
utilities such as formatting a disk. 


Are You Still a 
NCPA Member? 


Please check the mailing 
label...Has your membership 
expired? If so, why not 
renew your membership 
now while you’re thinking 
about it? (There’s a form on 
the back cover.) 


If your membership 
expired before 1997, then 


this will be your last 
Downlink! 


Memberships have been 
extended to allow for the 
fact that the Downlink hasn’t 
come out quarterly, but this 
is it for those with 1996 
expirations. If you are in 
that category, but feel you 
should have more issues 
coming anyway, please 
contact the secretary or 
president. 


User Interface 


FlexNet appears as a simple interactive 
application to the user. A number of 
commands are used to set up 
connections, access applications, etc. 
The user connects to the node's user port 
and sends the desired command. To 
initiate a connection, the user need 
merely specify the destination, although 
other options including manual routing 
are possible. The commands available to 
the user are summarized below. A 
complete description of all commands is 
given in the Sysop documentation, 
presently available in German, but 
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expected to be translated to English 
before Autumn 1995. 


<A>ktuell (Current_info) 

Displays a current-interest text 
uploaded by the sysop. 
<B>eacon 

Displays the Beacon text. From this 
file one can see which beacon is sent at 
what interval from which ports. 
<C>onverse 

Starts FlexNet Converse mode (if 
sent without a call sign following, 
otherwise see CONNECT below). 255 
channels are available. Function and 
usage of the FlexNet Converse mode is 
similar to other popular conference 
systems. 
<C>onnect 

Starts a connect request to another 
station when followed by a call sign. A 
connect command can also be 
established by the user without being 
connected to the node by specifying the 
entry and exit points of the network, and 
the destination. The node routes (see 
"Routing" below) SABM frames towards 
the destination and sends the message 
"link setup...". to the user. If the 
connection is ack'd by the destination 
station, the user receives the message 
"*** connected to <call>". If 
unsuccessful, the message "*** failure 
with <call>" is sent to the user. If a DM 
is received from the destination, the 
message "*** busy from <call>" is sent 
to the user. The connect request can be 
broken by sending a <CR> or a new 
connect request. If a user attempts to 
connect to a station he is already 
connected to, he receives the message 
"ee can't connect twice". This 
command can also be used to connect to 
a different user port at a node site that 
has more than one user port. For 
example, the command "C-7" connects 
the user to the port with SSID 7, which 
is acknowledged with the message "*** 
<call>: ssid ok" 

After using the Connect mode, ifthe 
other station disconnects, the user is 
reconnected to the last node connected 
to, which is announced with the message 
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"#* reconnected to <call>". 

It is not permitted to manually route 
a connect request to form a loop, where 
the connection passes through the same 
node twice. If an attempt is made, the 
user is informed with "*** <call> loop 
detected", and reconnected to the 
previous node. 
<D>estinations 

Shows the automatically-generated 
destination table. Information includes 
the call sign, SSID range, measured 
ping time (100 mS _ steps) and, 
optionally, the entire route to the 
destination. It should be noted that the 
destination list is nearly identical in 
every node in the network, since all 
updates are propagated throughout the 
entire network immediately. The user 
can also selectively view the destination 
table, for example "D HB9" shows all 
destinations having call signs beginning 
with HB9. 
<F>ind 

This command, one of the most 
powerful in FlexNet, sends a request to 
all nodes in the network (can be limited 
by the sysop, see also Setsearch) to find 
a particular station. Each node sends an 
UNproto frame addressed to the station 
to be found. If the station hears this 
frame, it will send a DM frame. If this 
occurs, a message is sent back to the user 
exactly where the desired station can be 
found. If there is no response, the user 
receives no message. Since UNproto 
frames can get lost, the user should send 
the command a few times to be sure. 
Naturally, the AX.25 protocol requires 
that the correct SSID be used. 
<H>elp 

Sends a help file uploaded by the 
sysop. 
<I>nfo 

Sends an information file uploaded 
by the sysop 
<L>inks 

Lists the sysop-defined link table, 
showing all ports, neighboring nodes, 
and their status. 
<LO>cal 

Sends the node's connect text file. 
Always sent when connecting directly to 


the user port, this command allows the 
text to be viewed remotely. 
<M>heard 

Displays up to 200 heard call signs 
with time stamp and channel number. 
<MY>call 

Displays the node's call sign and 
SSID range. 
<P>arameters 

Displays a detailed list ofall ports at 
the node, their parameters, various link 
statistics, and their status. 
<Q>uit 

Disconnects the user from the node, 
after the node sends "73!". 
<S>etsearch 

Shows which nodes will transmit the 
Find message. 
<U>sers 

Lists all users of the node, including 
those just passing through. Shows QSO 
number (internally generated), 
connection status, data frames unack'd, 
port, and call signs involved. 
<IO> (Input/Ouptut) 

Shows status of each of the 16 
binary inputs and outputs (RMNC 
version). 

Sysop Commands: The following 
additional or expanded commands are 
available exclusively to the sysop: 


<L>inks Set links list 
<M>ycall Set call sign and SSID 
range 
<P>arms Set various parameters 
<IO> Read all input lines and/or 
set all output lines 
<CA> Send a CALibrate signal 
<K>ill Kill a specific QSO 
<MO>de Set HDLC parameters 
<SY>sop sysop authentication 
<W?>rite upload various text files 
<T>race monitor all activity on a 
channel remotely 
<RESET> Cold reset 
<RESTART> Warm reset 


Connection Phases 


There are four possible phases for any 
given connection or QSO: Link Setup; 
Information Transfer; Link Failure; and 
Disconnect. Each phase is discussed 
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briefly: 


1. Link Setup 
During a connection setup, the 


connect (SABM) frames are simply 
routed through the network (see 
"Routing Methods", below), without 
being directly acknowledged (No UA 
Frame). Thus, a connection can only be 
made when the destination station is 
actually available, for it is the only 
station that will acknowledge the SABM 
frame. 

When the called — station 
acknowledges the connection with a UA 
frame, it is passed back (again without 
any hop-by-hop ack) to the calling 
station. At this point, there are two 
QSOs in the QSO list on every node 
involved: one from calling station to 
destination station and one in the reverse 
direction. Once the calling station 
receives the destination station's UA 
frame, the link is established (as a 
Virtual Circuit) and information transfer 


can begin. 
The reason for this method, instead 
of the more conventional direct 


acknowledge for SABM frames, is that 
very few network resources are wasted 
on connect requests that cannot be 
established, yet good connections are 
established fairly quickly. In the FlexNet 
network installed in Europe, typical 
response times from end to end are on 
the order of a few seconds, so timeouts, 
lost packets, and other problems are 
rare. 
2. Information transfer 

During the information transfer 
phase of a QSO a_ 'Hop-by-hop 
Acknowledge' is used. Each I-Frame 
(packet frame containing some 
information) from one or the other 
station is directly acknowledged by the 
node and then passed along to the next 
node along the path (also directly ack'd). 
Retries caused by whatever reason on a 
given link are thus only retries across 
one link and not across the entire path. 

The entire path is completely 
transparent to PIDs. Once the Virtual 
Circuit is set up, any manner of data 
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(such as TCP/IP or other protocols) will 
pass transparently through the network 
without any alterations. 
3. Link failure 

If, during information transfer, the 
path is broken for some reason, the end 
nodes report the link failure to both 
stations with the message '*** DBOxxx 
--> Link Failure" and the session is 
disconnected. 
4. Disconnect 

If station A sends a disconnect 
frame, it is immediately ack'd by the 
local node. The node then attempts to 
sever the connection to station B. If there 
is no data remaining 'in the pipeline’ for 
station B, the disconnect occurs 
immediately. If data remains, it is first 
passed to station B and then the link is 
disconnected. If station B had sent data 
to station A, it is lost. 


Routing Methods 


To connect, it is only necessary for the 
user to specify the point of entry to the 
network and the destination. There are 
four methods available to route the users 
connect request: 

1. Routing by destination table 

2. Routing by link table 

3. Routing by Heard list 

4. Routing by SSID 


Routing is only performed for the 
Connect (SABM) frame. Once the 
Virtual Circuit is set up (the UA of the 
SABM is received by the calling 
station), all subsequent frames take the 
exact same path. If a failure occurs, the 
link is torn down after informing both 
ends of the failure. A failed link must be 
reestablished manually. 


1. Routing by destination table 
The first method is based upon 


routing by call sign information. 
Thereby seeks the node, the next 
available node call sign of the received 
frames, and compares this with a table of 
calls that have been stored in a 
destination table by the autorouter. If a 
match is found, the call is passed along 


to the specified neighbor. [NOTE: All 
node call signs begin with DBO...] 

Example: DBOODW has _ the 
following links: 

1: DBOKT 

2: DBOAAC 

3: DBOIE 
and knows the following destinations: 
DBOEQ, DBOZDF, etc. 


The frame 
<fm DG3FBL to DK7WJ via 
DBOODW,DBOZDF> 
is expanded to: 
<fm DG3FBL to DK7WJ via 


DBOODW,DBOAAC,DBOZDF> 

This is because DBOODW knows 
that DBOAAC (which it has a direct link 
to, on Port 2) is the next (and best 
choice) node along the path to DBOZDF. 
Thus, the frame is sent via Port 2, 
despite the fact that there is no direct 
link to DBOZDF. The ‘best' path is 
always selected for any given 
destination, as determined by the 
average 'ping' time for a given path. 

The node sends out test frames 
("Pings") to each neighbor and then 
stores the round-trip response time. 
Using the ping information, the 
destination tables are constantly updated 
in real time. If a destination becomes 
available (or unavailable), that 
information is instantly broadcast 
throughout the network (limited only by 
the propagation time through the 
network), thus all destination tables are 
nearly identical. The destination table is 
built automatically and cannot be 
changed by the operators. It is thus 
assured that only accessible destinations 
are forwarded and instantly deleted when 
they (or their path) disappear. 


2. Routing by link table 
If the autorouter does not find an 


entry in the destination table, it then goes 
to the sysop-defined link table. If a 
pre-defined route is found here, the 
frame is sent to the specified neighbor 
(on a specified port) for handling. The 
link table normally contains only the 
direct neighbors, that is, those nodes 
having a direct link with the node. 
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Example: DBOODW has the following 
links: 

1: DBOKT 

2: DBOAAC 

3: DBOIE 

4: DBOAIS 
The frame 
<fm DG3FBL to 
DBOODW,DBOAIS> 
would be routed to Port 4 so long as no 
entry exists in the destination table, 
because DBOAIS is known in the link 
table. Hopefully, DBOAIS would have a 
route to DBOODW. 


DK7WJ via 


3. Routing by Heard list 
The node stores the last 200 directly 
heard call signs in an internal list. This 


Location 
California City 
Castro Valley 


Chico 


Hanford 


Livermore 
Los Gatos 


Mountain View 
Oakdale 
Penngrove 
Reno, Nevada 


Rio Linda 
San Francisco 


Bob Vallio - W6RGG 
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list remains in memory until a RESET 
occurs. An entry to this list occurs only 
when a station has an active connection, 
or when it is found using the 'Seek' 
command. At first, the node uses the 
SSID of the desired station to establish a 
connection but, if there is no response, 
then the SSID is ignored. It is therefore 
without problems possible to be in 
STBY on various ports with various 
SSIDs, so that one can always be found 
on the correct port. Incoming connect 
requests or also UNproto frames are 
routed with this list. 


4. Routing by SSID 
A final chance for the node to route 


frames is based upon the SSID. Specific 


DX Spotting Nodes 


June 1999 
Alias Frequency 


-490 


channels can be arranged by SSID (this 
can also be done by Port number). This 
is shown with the PARMS command. To 
use the SSID routing, the user specifies 
the SSID (Port) that the frame should be 
sent from. 

Example: DBOODW has __ the 
following arrangement of SSID versus 
Channel numbers: Channel | has SSID 
0, Channel 5 has SSID 12, Channel 6 has 
SSID 3, etc. If a connect frame arrives 
that has specified a SSID for DBOODW, 
the frame is routed directly to the 
channel specified by the SSID: 

The frame <fm DG3FBL to DK7WJ 
via DBOODW-12> is routed to channel 
5, which has the SSID of 12, so long as 
no other way to DK7WJ is known. 


Coverage 


Antelope Valley area 


-490 
.770 
670 
.670 
950 
. 950 
.770 
.770 
.770 
580 
580 
- 950 
580 
. 950 


Chico 


Mt. Ad 


.580 
.950 
.500 
950 
.670 


Low 


(2400 baud) 


4 
4 
4 
4 
4 
4 
4 
4 
4 
14 
14 
4 
4 
4 
4 
4 
4 
4 
4 
4 
4 


OPFADFAADFP DDN AHBOO OB Bs 


wsixrgg@crl.com 


Oroville, 
South Fork Mtn - Redding area 
Bear Mtn, 
laide, 


Oak Peak 
East, West, 


South SF Bay area 
Red Bluff 


Fresno area 
Bakersfield area 


Oakhurst 


Tri-Vall 
Santa Cruz Mtns, 
Santa Cruz/Los Gatos 
Mountain View, 
Modesto area 

Sonoma County 
-950,146.58,441.500 


Sacramento, 
East Bay and North 


ley area 
Monterey Bay 


San Jose area 


(2400 baud), 51.7 


Level in Reno 
Virginia City, 


NV 


Woodland, Davis 


Summer, 1999 


The following frame is sent out 
from channel 5: <fm DG3FBL to 
DK7WJ v DBOODW-3*>, which clearly 
shown where the frame came from (in 
this case, channel 6 has the SSID 3). 
This also carries the entry node 
information. This turnaround of SSIDs is 
also notable in that every frame shows 
where it came from. 

One of the most important features 
of FlexNet is that all connections are 
reversible, that is, you are always 
provided sufficient info to have the same 
connection in the reverse direction. This 
routing method is naturally used above 
all for user access. If all of these routing 
methods fail, the connect frame is lost. If 
this occurs when the user is connected to 
the node, the message "*** <call sign>: 
can't route" is sent to the user. If the user 
issued a connect command when 
disconnected from the node, the TNC 
will eventually reach the RETry limit. 


Adaptive Parameters 


All level 1 and level 2 parameters within 
the network (including user access 
channels) are either self-adjusting 
according to the current channel 
conditions or fixed in the software. The 
only exception to this is TXDelay, which 
is set by the sysop. A RETry limit of 10 
is used to ensure a quick recovery for 
links subjected to temporary 
interference. Regular polling is used to 
verify that links are operational as well 
as to determine the actual one-way or 
round trip data transfer time. 

The polling interval, controlled by 
FRAck (T1), varies according to channel 
conditions. If FRAck is small, polling 
occurs no sooner than every 90 seconds, 
lengthening when FRAck becomes 
larger. Each node polls only its 
neighbors. The round-trip turnaround 
time is used to adjust FRAck (T1) to the 
time it takes for the neighboring station 
to acknowledge I-frames, and is also 
used (along with other factors) by the 
autorouter to determine the best (fastest) 
path to other stations. 

MAXframe is regulated according 
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to the capability of the link. When the 
other station receives all frames without 
problems, MAXframe runs as high as 7. 
At 1200 baud, 7 frames in a row are 
seldom sent, since the maximum 
key-down time is limited to about 12 
seconds. When multiple streams are 
active, the 12 seconds is divided up and 
shared. When the other station begins 
missing frames (for example by sending 
reject frames), MAX frame is reduced. In 
this case, the throughput is actually 
increased with a lower MAXframe. It 
should be noted that evaluation checks 
the link quality TO the other station, not 
FROM the other station, and that the 
value changes as necessary. A poll, in 
which all frames are acknowledged, or 
with lost acknowledgments, don't reduce 
MAXframe. 

P-Persistence is the critical 
parameter when many users are on the 
channel simultaneously. A _ fixed 
parameter is, at best, a compromise 
between collision potential and transmit 
potential. FlexNet notes the number of 
users on the channel, as well as the data 
rate and other factors, and adjusts 
P-Persistence to offer the best 
performance at all times. Aggressive 
stations no longer have the advantage of 
faster performance at the expense of 
weaker stations, yet fast downloads 
remain feasible when channel activity is 
low. The improvement over a fixed 
parameter is most notable on duplex user 
ports (the most common in Germany), 
but improvement is noticeable on 
simplex channels as well. 

Concerning TXDelay, if the node 
hears more than 100 ms of flags from a 
user station, which indicates an 
excessive TXDelay setting in the users 
TNC, a polite message is sent informing 
the user of this fact, and then 
disconnects. Thus, a user running 
excessive TXDelay cannot use the 
network until the problem is corrected. 


It would be highly desirable if user 
software were to also follow the trend 
towards full adaptation to the channel 
conditions. It is clear that a computer can 


adjust to prevailing conditions faster and 
more accurately than a human, not to 
mention the fact than most users are 
totally baffled by TNC parameters 
anyway. Other problems also are caused 
by using a single fixed parameter to 
control a constantly changing channel, 
which would be resolved with adaptive 
user software. PC/FlexNet can be 
installed as user software to take full 
advantage of adaptive parameter 
adjustment by simply omitting the Node 
module. It becomes a powerful yet 
flexible replacement for permanent TNC 
emulations like TFPCX - simply use 
FlexNet with TFEMU and channel 
drivers as needed. Setup is simple, with 
only one parameter (TXDelay) requiring 
operator input. 


Working with TheNET 


It is relatively easy and painless to 
include TheNET network nodes into a 
FlexNet network. Each TheNET node 
that interfaces directly with a FlexNet 
node appears in the FlexNet destination 
table. The interface must be 
single-stepped manually, but no serious 
problems occur as TheNET users are 
used to single-stepping ;-) 


For Further Information 


This overview is necessarily brief. 
Complete details are available with the 
software) or in a separate printed 
documentation from the author. 


References: 

G. Jost, DK7WJ and J. Sonnabend, 
DG3FBL, "FlexNet, the European 
Solution", Proceedings of the 9th ARRL 
Computer Networking Conference, 


pp127-133, 1990. 


G. Jost, DK7WJ, "FlexNet Sysop 
Manual v3.3", 2nd edition, 1995. 
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President's Message 


Gary Mitchell, WB6YRU 


Downlink 


First, I must once again apologize 
about the Downlink publishing schedule. 
It seems our latest editor followed suit 
with our previous two editors and 
decided to leave us high & dry. And, 
once again, I find myself having to fill in 
as editor pro tem. 

This was supposed to be the winter 
“99 issue. Perhaps I should have not 
waited as long as I did before jumping 
in, but I was hoping against hope our 
editor would come through after all. 

As before, memberships will be 
automatically extended to allow for the 
fact that the issues haven’t come out on 
a quarterly basis. 


Band Plan 


The board has voted to include non- 
digital segments in the digital band plan. 
The NCPA will not be doing band 
planning in the non-digital segments, this 
is just recognition of other band usage. 

The digital band plan will continue 
to list digital frequencies individually, 
but non-digital will be listed mostly as 
segments—similar to the ARRL 
suggested band plan listing. 

Every effort will be made to make 
the listing complete and accurate, but 
there may be some adjustments as new 
information comes in. 

It is hoped this additional data will 
make the digital band plan more useful 
to the users in that the one document will 
give a better picture of various activities. 
Also, it will make a good reference for 
the board when trying to decide on any 
new digital segments. 

We expect to have this pretty much 
done in time for Pacificon ‘99. 
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For those who haven’t heard, the 
Spectrum Management Committee died 
in the crib. NARCC pulled out rather 
abruptly with dubious reasoning. Since 
the SMC needs the cooperation of all 
major players in the region and NARCC 
is a major player, the SMC was 
effectively gutted. 

This is really unfortunate—the region 
would have benefitted from having a 
unified band planning committee. 

There has been some talk about 
trying again, with perhaps SHARKK 
representing repeater interests, but this is 
just an idea. If anything more comes of 
it, Pll let you know. 


70 cm Digital 


For a very long time there has been 
talk about establishing a badly needed 
digital sub-band at 70 cm. Currently, 
there is only one widely recognized 
digital frequency at 70 cm in this region, 
441.50 MHz. 

After much _ negotiation, 
deliberation, and searching for a good 
sub-band, it seems we are now 
extremely close to finally having at least 
one digital sub-band at 70 cm. The most 
likely segment as of this writing would 
start at 433.0 MHz and end 434.0 MHz. 

In years past, NARCC’s 70 cm 
coordinator put digital users in this 
segment on an individual basis. The fact 
that the vast majority of current digital 
operations already takes place in this 
segment made it a _ highly likely 
candidate as a digital sub-band. 

So far, the only objection to this 
segment is that some (very little) ATV 
activity exists with a carrier at 434.0 
MHz. Such an ATV signal covers from 
roughly 433.0 to 439.0 MHz. This does 
not follow the ARRL band plan. There 
is an ATV segment from 438 to 444 
mentioned in the ARRL band plan, but 
NARCC has repeaters assigned there. 
I’m told NARCC originally had ATV go 


to 434 MHz. I find this is rather odd 
since it was also NARCC that originally 
put digital users at 433.x MHz. 

It seems there is only one significant 
ATV presence at 434, an ATV repeater 
near Stanford. The repeater operator 
said there are multiple inputs, 434 MHz 
is still there only for the “legacy” users 
(a few remaining “sticks-in-the-mud” 
with older equipment). He further said 
that there are very few legacy users and 
they rarely check in on that input. 

The 70 cm band is heavily used, and 
in my opinion, it’s a very bad idea to 
reserve so much band width—a whopping 
six MHz-for such light and sporadic 
usage. 

However, in my mind, there is a 
MUCH more compelling reason for 
ATV to stop activity at 434 MHz-it puts 
the ATV signal smack-dab on the 
internationally recognized satellite sub- 
band at 435.0 to 438.0 MHz! When this 
was mentioned to the ATV guys, they 
mumbled something about not using it 
when satellites are overhead. I may be 
wrong about this, but I seriously doubt 
they go so far as to track all amateur 
satellites that use 70 cm and shut down 
when one is above the horizon. That 
claim is even more questionable in the 
case of regularly scheduled ATV nets. 


Therefore, I am pushing for the new 
70 cm digital segment to be 433.x and to 
not recognize ATV at 433-438 MHz. 
Every indication is that this would affect 
very few ATV people anyway. If 
anyone has other information or 
comments about this proposed digital 
assignment, please let me know. 


General Meeting 


We plan to once again have our 
general meeting at Pacificon ‘99. It isn’t 
confirmed yet, but as of this writing it 
will be Oct 17, Sunday afternoon in the 


Sunvalley room at the Concord 
Sheraton. Stay tuned.... EOF 
Summer, 1999 


AA4RE BBS Program 
versus Y2K 


by Mike Fahmie, WA6ZTY 


The AA4RE BBS program was written 
by Roy Engehausen (AA4RE) in the 
mid '80's and was regularly maintained 
and updated until mid 1994. It is 
currently used by many of the PSNC 
BBS's (N6EEG, W6CUS, WA6YH\J, 
KD6JZZ, N6CKV, W9HGI, W6SF, & 
KD6DG; to name a few) and a large 
number of packet BBS's worldwide. I 
have used it here at N6EEG for about 6 
years and like it very much. 


Some of you may have noticed the 
packet bulletin that Fred, K6RAU, wrote 
about the Y2K weaknesses that he found 
in the MSYS BBS system a few months 
ago. It seems that MSYS handles the 
millennia by incrementing from '99 to 
'100, not such a bad thing you might say, 
but that third digit just doesn't fit into the 
YYMMDD header format used 
throughout the BBS world. 


Reading of Fred’s discovery, I became 
curious about how the AA4RE software 
would fare come next January. Due to a 
chance meeting with another ham at the 
Dayton Hamvention 3 years ago, I came 
into possession of a copy of the 
PASCAL source code for Roy’s BBS 
program, all 3.5 megabytes spread out 
over 333 separate files. Wow, there was 
a lot more to this than I had ever 
imagined and I had not worked with 
PASCAL before. 


I searched the source code for keywords 
such as; time, 19, 99, date, year, month, 
leap, etc..., eventually compiling a list of 
functions and subroutines that dealt with 
the mechanics of time keeping and the 
programs that called upon these 
services. Roy used three different 
formats within his program to relate it to 
time/date; 


1.) DATETIME is a BORLAND 
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PASCAL datatype provided by the 
compiler that provides an array of 
integers for year, month, day, hour, 
minute, second, dayofweek. This is the 
format used when a program asks the 
operating system for date/time services, 
such as reading the CPU calendar chip. 
The compiler documentation states that 
its routines will work until 2099 or so. 


2.) YYMMDD/HHMMSS, an ASCII 
string format used to relate time to a 
BBS user or for use in a BBS message 
header, example 990208 is February 8th 
of 1999. YY is assumed to be 19YY. 


3.) Roy’s internal format for time is a 32 
bit LONG INTEGER format that 
indicates the number of seconds that 
have passed since January 1, 1980. This 
is the format that is used for most all of 
the important timekeeping tasks in the 
program. This should work fine until 
about 2132 when the 32 bit value 
overflows. 


In the course of operation, it is necessary 
to frequently go from one format to 
another, so Roy wrote a collection of 
sub-routines to translate any one of these 
formats into the others and it is here 
where most of the weaknesses lie. Since 
the YYMMDD format uses only 2 digits 
to relate a 4 digit year, the translation 
routines assume the missing two digits 
are "19" and dutifully append those 
digits to the two provided ones to 
produce a 4 digit year. That worked 
really well, at least until now. 


Imagine what happens on Jan 1, 2000 
when 00/01/01 is translated into Roy’s 
LONG INTEGER format...lets see, the 
year 2000 represents about 631 million 
seconds since 1980, but since the 
program assumes that all years begin 
with 19, it will try to calculate the 
number of seconds in -80 years 
(1900-1980) instead of in +20 years 
(2000-1980)! That comes to about -2.5 
billion seconds! Want to know what 
happens when the rest of the program 
sees negative seconds? Just try writing 
a check to the LR.S. for -$500 to pay off 


your income tax in April. Tests have 
shown that the BBS program will begin 
generating error messages within 
seconds of the New Years fireworks, and 
become non _ functional almost 
immediately. 


Since Roy left packet a few years ago he 
is no longer maintaining the program, a 
friend and I have undertaken the task of 
making it Y2K compliant. We have 
meticulously searched through the code 
and believe we have found and updated 
all of the non-compliant programming. 
Unfortunately, we were unable to make 
it immortal due to various existing 
limitations, but it should now run well 
from 1990 to 2090. 


An alpha version is currently undergoing 
tests and will be released free of charge 
to the amateur community as soon as we 
have convinced ourselves that everything 
is in order. This release will also rectify 
a compiler bug that caused the BBS to 
crash on faster processors (>166 MHz 


Clk.). 
EOF) 


APRS move 
to 144.39 


The APRS move to 144.39 has been 
very successful. Most of the high-level 
digi's in California made the move (only 
a couple went off the air instead) and 
coverage works great! No more turning 
the frequency knob on long trips! 


The current concern is that it works 
too well. Most of the high-level sites are 
now running the WIDE n-n code, which 
allows stations to simply specify how 
many hops they want from the high-level 
sites...the Digi's then perform call sign 
substitution, try to reduce duplicate 
packets (avoiding some LAN-level 
collisions), and propagate the packets 
‘far and wide'. Boiling it down, 
California is starting to look like a 
congested LAN again as_north-end 
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packets go south and south-end go north, 
and messages start to take a long time to 
get ACKs back. 


There is a message on _ the 
CA-APRS- mailing list 
(aprs@lists.monterey.edu) which 
recommends some of the things we 
learned before, living in a Digi-rich area, 
including use of a local, explicit 
digi-path for most folks with mobile 
trackers, and using the APRS.NET 
java-based web browser for APRS to 
monitor for folks outside our local areas. 
(After all, how many folks in Riverside 
want to see someone's tracker packets 
from Eureka as is sits in the driveway 
overnight?) Ours is a problem of 
abundance, and we're using the Internet, 
and printed media to help educate the 
masses on how to better use the 


bandwidth we have. 


Dave Harris, NoUOW 


ARRL COMMENTS 
ON CENTRAL 
STATES PETITION 


In comments to the FCC, the ARRL says 
it supports the objectives of the Central 
States VHF Society's recent petition to 
formally segregate wideband and 
narrowband modes on VHF and UHF. 
But, the League says, the Society's 
petition fails to make a case to 
implement any new FCC rules. The 
petition, filed in June, would amend 
FCC rules to eliminate interference from 
FM and packet in the so-called 
weak-signal portions of the 6 meter, 2 
meter, 1.25 meter,, and 70 cm bands. 
The FCC has assigned RM-9673 to the 
CSVHFS petition. 


In its comments, the League said it 
generally supports the intent of the 
petition but "does not support the 
regulatory relief requested" because the 
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Packet Bulletin Board Systems 
August 1999 


Call-SID Location 


Exeter 
Fremont 
Gilroy 
Los Gatos 


Redding 
Richmond 


Richmond 


San Jose 
San Jose 
Sebastopol 
Sonora 


Stockton 
Sunnyvale 


Walnut Creek 


Willits 
Yuba City 


9600 Baud Port 
TCP/IP Port 
Currently Inactive 


petition doesn't spell out the extent of 
the interference problem. The League 
said the number of complaints of 
harmful interference to narrowband, 
weak-signal modes it typically sees 
doesn't justify additional 
regulation—although the ARRL 
conceded that the actual number of 
incidents might be higher than 


Citrus Heights 


North Highlands 


San Francisco 


South Lake Tahoe 
Stanford Univ 


User Ports 
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os BhoOPoBKROOKRKROBRTOBKRP AK HROOOKR OD 


complaints to ARRL HQ would indicate. 
The League said it prefers "reliance on 
established voluntary band plans" 


coupled with "some Commission 
support" to address the CSVHFS 
concerns. The ARRL took the 


opportunity to again call on the FCC to 
acknowledge "that VHF and UHF 
operation in accordance with established 
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band plans is 'good amateur practice” 
and it urged the Commission to support 
compliance with band plans to prevent 
interference to weak-signal operations. 


The League said it shares the Society's 
concerns about wideband FM and packet 
QRM to weak signal work but suggested 
that new regulations could stifle 
flexibility in the Amateur Service rules. 
The ARRL said it would rather see 
reliance on "the self-regulatory abilities 
of the Amateur Service, as reflected in 
voluntary band plans" than new FCC 
regulations. 


The League suggested educational 
efforts as an appropriate remedy for 
newcomers and others unfamiliar with 
these amateur conventions. 


A copy of the League's comments, filed 
July 28, is available on ARRLWeb at 
http://www.arrl.org/announce/ 
regulatory/csvhfs.html. 


From The ARRL Letter, August 13, 1999 


EOF 


Minutes of Annual 
Meeting, 1998 


Held at Pacificon ‘98 October 
18, 1998 
Sheraton Hotel, Concord 


Called to order at 2:09 PM by president, 
Gary WB6YRU. 


We don’t have a quorum. Since the 
ARRL forum is still in progress, it was 
decided that we reconvene after the 
forum. 


Reconvened at 2:45 PM. Attendance: 
N6HM, WA6ZTY, WB9LOZ, W6RGG, 
K6CDO, W6BNG, KE6LW, WB6YRU, 
KM6PX, KH6JUZ, K6HLE, KD6FJI, 
KJ9U, N6UOW. (We now have a 
quorum.) 


Summer, 1999 


MEETINGS 


The last general meeting in the South 
Bay was not very well attended. N6HM: 
motion to change the bylaws to allow 
having the general meeting at Pacificon. 
The consensus was this should be done, 
but a change to the bylaws requires 
advanced notice to the membership. 
This issue will be voted on at the next 
general meeting. 


It was decided we explore further the 
idea of having meetings via 
teleconference/internet. K6CDO will 
look into it further and report back. 


ELECTION OF DIRECTORS 


Roy KA6EYH (not present) previously 
stated he would stay on as director and 
treasurer. Mel W6BNG, Howard 
N6HM, Dave N6UOW, Don K6CDO, 
Bob W6RGG, and Gary WB6YRU each 


wanted to stay on as director. New 
nominations: Barry Barnes (BBS) 
KE6LW. 


W6RGG: motion to close nominations, 
seconded and passed. 

Vote to approve the slate of directors: 13 
in favor, | against. 

The new directors are: Mel Gregonis 
(BBS) W6BNG; Don Root (Emergency 
Com.) K6CDO; Roy Wysling (BBS & 
TCP/IP) KA6EYH; Howard Krawetz 
(Keyboard) N6HM; Barry Barnes 
(BBS) KE6LW; Bob Vallio (DXPSN) 
WO6RGG; Dave "Zonker" Harris (APRS) 
N6UOW; Gary Mitchell (BBS) 
WB6YRU 


BAND PLANNING 


WBO6YRU: recap of what happened with 
NARCC and the SMC (Spectrum 
Management Committee) and that we 
found NARCC difficult to work with. 
As to proceeding with allocations at 70 
cm, some research is already in progress 
(ATV, SHARKK). K6CDO suggests 
also finding out what So. CA is doing 
with digital at 70 cm. 


KM6PX gave a brief summary of 
SHARKK. One idea is to form a new 
band planning organization, something 
like what the SMC was going to be. 
This could even take the form of a 
merger with SHARKK. 


WO6RGG: motion to look into working 
with SHARKK, etc. to form a SMC of 
some kind independent of NARCC. 
Approved unanimously. Consensus is to 
go ahead with allocating at least one 
digital segment at 70 cm, probably a one 
MHz bandwidth segment at 433 MHz. 


COORDINATION 


WB6YRU, N6HM: reviewed board’s 
vote to not do any digital coordination. 
The only digital segment that isn’t 
coordinated by one of the packet special 
interest groups is the relatively new 219- 
220 MHz segment. 


N6HM: motion that NCPA contact the 
ARRL and work toward the goal of 
being the designated coordinator of 219- 
220 MHz in this region. Motion passed 
unanimously. 


INTERNET/PACKET 


Discussed the new packet network idea-- 
merging packet (especially BBS) with 
the internet. KM6PX mentions he might 
be willing to do the programming, but 
there are problems with the whole idea. 
The main thing is usage of the BBS 
network is down and merging it with the 
internet may not be enough to entice 
users back. KH6JUZ says low speed is 
one of the biggest problems with packet 
today and he is ready to put in 
equipment for a minimum of 19.2 kbaud 
if only there was room for it at 70 cm. 
He says a 100 kHz bandwidth channel 
would be fine. 

K6CDO: motion that the NCPA pursue 
this new network idea and work toward 
higher speed activity. Passed 
unanimously. 


Adjourned 4PM. 


EOF 
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NCPA board of Directors Electronic Meeting 


Excerpts of the NCPA board remailer 
traffic, September 6, 1998 through June 
17, 1999. Compiled by Gary Mitchell 
WB6YRU (full text of traffic is 


available). 


Sep 6, 1998 

Gary Mitchell, WB6YRU: 

The NCPA will hold a general meeting 
at Pacificon '98 in Concord 


(August 1998 version of Packet Band 
Plan was posted) 


Sep_9, 1998 

cross-post from netsig@tapr.org: 

Tim KASRYF suggests faster packet is 
fine, but what's really needed is better 
features and plug & play software. Also, 
packet needs to have some of the 
features of the internet. 


Sep 12, 1998 

Gary Mitchell, WB6YRU 

On the subject of making packet more 
interesting--specifically having it work with 
the internet, the FCC regulations on content 
are a problem. Here's an excerpt from 
TAPR's NETSIG remailer: 


David Rush: 

I'malso concerned about the content coming 
from the Internet. I'd love to have a 
free-flowing gateway, but I'm not thrilled 
about the prospect of my call sign being on 
the first hop off the Internet when profanity 
and commercial stuff starts flowing through. 


If packet is to move forward with something 
like this, the content restrictions need work. 
The FCC already moved in that direction 
recently, limiting liability to the first BBS in 
a forwarding chain. However, I believe it's 
still too restrictive. 


Sep _ 27, 1998 
Howard, N6HM: 


About allocating one or two digital segments 
at 70 cm... I think its time we have a meeting 
and select some UHF frequencies and 
publish our intentions to coordinate them and 
get them in place. 
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Oct. 1, 1998 

Dave "Zonker" Harris, NoUOW: 

There is some talk in the APRS community 
about the need for a 9600 baud UHF 
channel. 


Oct 3, 1998 

Gary Mitchell, WB6YRU: 

The independent Spectrum Management 
Committee effectively died when NARCC 
pulled out. NARCC's true motives weren't 
clear, but they tried to make it look like 
somehow it was NCPA's fault. So, we're 
back to allocating spectrum on our own. 


Don Smith W6NKF: 

NARCC has not pulled out of the 
SMC...NARCC has reorganized the 
committee....It is still a standing committee 
sponsored by NARCC. 


Gary: 
The SMC was *not* NARCC's to reorganize. 
It was an independent committee with 
NARCC, NCPA, and others as equal 
members. Unfortunately, such a committee 
needs participation from all the major 
players, NARCC has effectively killed it by 
pulling out. 


Oct 4, 1998 
Discussion about contacting other amateur 
organizations on frequency usage. 


Mike Stickney KM6PX: 
(Posted 70 cm band plans from various 
groups.) 


I think the SMC is a good idea but needs to 
be totally independent from any coordination 
body. 


To say that NARCC *or* NCPA is going to 
"create" this body is like asking the fox to 
guard the chicken coop. 


(Mike describes how the SMC should be 
made of representatives.) 


Gary: 
That's how the SMC was supposed to be. 
(Describes some of the history of this issue.) 


(Discussion about some of mechanics of 
allocating channels in 70 cm.) 


Oct 9, 1998 

Gary Mitchell, WB6YRU: 

Howard N6HM just informed me _ that 
Pacificon has a free table available for two or 
three clubs. We won't have room for the 
demo's that we had in previous years, but it 
will be enough for handouts etc. 


Oct 11, 1998 

Gary Mitchell, WB6YRU: 

(Gives notice of _NCPA meeting at 
Pacificon, includes agenda.) 


Oct. 20 1998 

Gary Mitchell WB6YRU 

(Posted minutes of NPCA meeting.) 
The new board now has to elect officers 


Zonker Harris: 
I'll toss my hat in for Secretary... 


Don Root: 
Iam willing to continue as Newsletter Editor. 


Gary: 
The candidates for NCPA officer positions so 
far: 


President: Gary Mitchell WB6YRU 

V.P. (still open) 

Secretary: Dave "Zonker" Harris NoUOW 
Treasurer: Roy Wysling KA6EYH 
Editor: Don Root K6CDO 


The newly elected NCPA directors are: 
Mel Gregonis (BBS) W6BNG 
Don Root (Emergency Com.) K6CDO 
Roy Wysling (BBS & TCP/IP) KA6EYH 
Howard Krawetz (Keyboard) N6bHM 
Barry Barnes (BBS) KE6LW 
Bob Vallio (DXPSN) W6RGG 
Dave "Zonker" Harris (APRS) NoUOW 
Gary Mitchell (BBS) WB6YRU 


Nov 9, 1998 

Zonker Harris NoUOW: 

The General Membership of TASMA 
approved a motion to designate 144.390 
MHz for APRS. 

The Oregon Region Relay Council went to 
144.390 MHz last June for APRS. 


Nov 10, 1998 

Gary Mitchell WB6YRU: 

The FCC is undergoing a biennial review of 
Part 97 (WT Docket No. 98-143). 
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(Posts draft of comments to FCC regarding 
restrictions on 219-220 MHz usage. 
(Consensus is that it looks good as is and it 
should be sent in.) 


Dec. 20, 1998 
Don K6CDO is willing to run for V.P. 


Slate is: 

President: Gary Mitchell WB6YRU 

V.P. Don Root K6CDO 

Secretary: Dave "Zonker" Harris NoUOW 
Treasurer: Roy Wysling KA6EYH 
Editor: Don Root K6CDO 

Dec 21, 1998 


Discussion about allocation of 433.0 - 434.0 
MHz to digital, ATV, and other segments. 


Dave Harris: 

My contact advises that the Bay Area hosts 
three ATV groups: Mt. Diablo Output at 
427.25MHz. Channel width 426.00 to 
432.00. W2NYC (EX WD6GYH) San Jose, 
Same as above. Black Mtn. SUARC at 
434.00MHz. Channel width 432.75 to 
438.75 


Gary: 

One reason for targeting 433.x is because the 
vast majority of 70 cm digital is already 
there...been there for years. 

432.0-432.75 is for weak signal 

435 to 438 is satellite only (international) 


Howard N6HM: 
Crystal Peak ATV is on 426.25 MHz 


Zonker Harris NoUOW: 

The technical coordinators for the Black 
Mountain site says the 430 input is retained 
for "legacy users." 


Ray Riordan: 

I'm on the Black Mtn. ATV repeater. There 
is very little traffic on the 434 MHz input. 
Most of the users are on 1.2 GHz and some 
on 10 Ghz. 


Zonker Harris NsUOW 
This is from WF6R regarding the 434 ATV 
input: 


So, it seems that we don't want to step on the 
Weak Signal folks, and that the current 
allocations actually *are* at 433.xxx, and 
has been for a few years now. The 
international allocations for satellite are 
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reportedly at 435.0-438.0, also overlapping 
with the 434 channel. 


I make no effort to explain our use of 434 
MHz. It’s just the frequency we were told to 
use by NARCC back in the early '80s when 
the system went on the air. The 434 input 
has been troubled by digital users for years 
who never checked to see if anyone else was 
using that channel. Typically, ATV was not 
active during satellite passes. The biggest 
digital offenders were users of the Stanford 
digipeater. Oddly, Stanford also sponsors 
the Black Mtn ATV machine. 


There are only a few people left using the 
434 input. As I said earlier, its only there for 
the geezer factor, older folks who want it 
there because its "always been there" so the 
machine still listens to 434. 


Gary: 

It sounds to me like what we've got here is a 
staggering six MHz wide segment reserved 
for almost nothing. 


I believe that no matter what segment we 
pick, there's always going to be someone 
who will gripe. The best we can do is pick a 
spot with the least number. 


Also, the interference to their 434 ATV 
input comes from their own BBS...I just find 
that amusing. :) 


Dec. 23, 1998 
All of the directors voted yes to the slate of 
officers: 


President: Gary Mitchell WB6YRU 
V.P.: Don Root K6CDO 

Secretary: Dave "Zonker" Harris NoUOW 
Treasurer: Roy Wysling KA6EYH 
Editor: Don Root K6CDO 

Jan 1, 1999 

Gary Mitchell WB6YRU: 


Larry W6OMF (pres. Western States Weak 
Signal Society) reports interference from 
packet on 222.14. The stations are W6GO 
and N6TR. Those are both DXPSN. The 
weak signal people pretty much follow the 
ARRL's suggested band plan, which shows 
222.0 - 222.15 as weak signal. 


Jan 3, 1999 

Gary Mitchell WB6YRU: 

Currently, the digital band plan only lists 
digital frequencies. I propose it be expanded 
to recognize non-digital segments as well. 


(Discussion followed--all comments were 
positive.) 


Feb 3, 1999 

Vote to recognize non-digital band segments 
in the digital band plan 

5 Yes 

0 No 

1 not voting 

Motion passes 


Feb. 4, 1999 

Don Root K6CDO: 

Call For Articles for the NCPA Downlink. 
Deadline is February 15. 


Feb 12, 1999 

Gary Mitchell WB6YRU: 

Treasury is low, what about maybe raising 
dues to $15 per year? Our treasurer, Roy 
KA6EYH will be moving out of the area 
soon. Howard N6HM has agreed to take 
over as treasurer. 


About digital sub-band at 70 cm... Can we 
agree that 433.x is the primary segment to 
consider? 


About 222.14 MHz... PSNC indicates no 
BBS's on 223.68. We could re-allocate 
223.68 from BBS to DXPSN Forwarding so 
those two DX stations can move off of 
222.14. 


(More discussion about ATV & satellites 
from 433 to 438.) 


Feb 14, 1999 

Mike Fahmie WA6ZTY: 

There is an ATV station in San Rafael CA 
that operates 24 hours/day transmitting 
NOAA/NASA photographs. His video 
carrier is on 433.25 MHz so his signal 
occupies 432 MHz to 438 MHz. 


Gary: 
Hey, that sounds like *broadcasting* to me! 


Feb 22, 1999 

R. B. Vallio W6RGG: 

I propose that the DXPSN be granted NCPA 
sanction to use the frequency of 223.68 MHz 
for backbone connections between various 
nodes within the NCPA jurisdictional area. 
This move will allow DXPSN to remove any 
links now active on 222.14 MHz. 


Vote to release 222.14 to weak signal (from 
digital): 
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6 Yes 

0 No 

1 not voting 

The motion passes. 


Feb 28, 1999 

Gary Mitchell WB6YRU 

Roy KA6EYH is resigning as treasurer 
effective March 15, due to the fact that he'll 
be moving out of the area. Nominations are 
now open for a new treasurer. Howard 
N6HM has already offered to take the office. 


March 4, 1999 
Bill Edmondson reports his check for dues 
hasn't cleared (been 3 months) 


Vote for Howard N6HM to take over as 
treasurer: 

5 Yes 

0 No 

2 not voting 

Congratulations Howard! 


March 7, 1999 

Vote to re-allocate 223.68 to DXPSN 
backbone: 

5 Yes 

0 No 

2 not voting 

The proposal passes. 


The DXPSN is hereby requested to ask their 
two stations on 222.14 to move their 
forwarding activity to 223.68 at their earliest 
convenience. Reportedly a node is involved 
which is not practical to get to until the snow 
melts. We understand this may cause a delay 
on the order of months. 


April 17, 1999 
Gary Mitchell WB6YRU: 


NCPA web page has changed (again) it’s 
now http://www.n0ary.org/ncpa 


Sorry about yet another address change. 
Hopefully, it will stay this way for a while. 


May 11, 1999 
Gary Mitchell WB6YRU: 


Has anyone heard from our new editor, Don 
Root K6CDO lately? The Downlink is over 
due now and I haven't been able to get 
through to him. (Here we go again.) 


May 30, 1999 
Gary Mitchell, WB6YRU: 


Let's get started on the expanded band plan 
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(satellite sub-bands are listed) 


Carol A Byers: 
(extensive list of satellite frequencies) 


Gary: 

Except for the 144.30 - 144.43 segment, the 
list I gave and the one Carol has given appear 
to be the same. 


Discussion about 144.30-144.50 

Carol questions digital allocations here. 
Gary talks about the history behind this. 
Cap Pennell posts information about how 
AMSAT was involved with the move of 
APRS to 144.39 from 145.79. 


June 2, 1999 

Gary Mitchell, WB6YRU: 

I've recently been in contact with the 
president of WSWSS (Western States Weak 
Signal Society). He has confirmed that the 
following list is pretty much accurate and 
complete as far as weak signal is concerned. 
They consider all SSB and CW to be weak 
signal. 


(Posted list of weak signal frequencies) 


June 5, 1999 

Vote to accept listed satellite frequencies: 
Five YES 

Zero NO 

One not voting 

The motion passes. 


Gary Mitchell WB6YRU: 
(Posted list of simplex frequencies, asked for 
corrections). 


Bob W6RGG: 

> 146.42 - 146.56 simplex 

Should be 146.415 - 146.565 and they are 
channels at 15 kHz spacing. 


> 147.42 - 147.58 simplex 
Should be 147.405 - 147.585, same 15 kHz 
spacing. 


Bob also pointed out that there is a DXPSN 
station on 146.595. This frequency is not in 
the packet band plan, but is noted in the 
Repeater Directory as a simplex channel. 


Bob Wilkins N6FRI: 

You may want to consider 441.000 as FM 
simplex (mostly remote bases) in Northern 
CA 


June 16, 1999 

Vote to accept list 
frequencies: 

Five YES 

Zero NO 

One not voting 

The motion passes. 


of weak signal 


Gary Mitchell, WB6YRU: 
(Posts updated simplex list) 


146.595 is reportedly used locally by some 
DXPSN stations. Do we want to consider it 
digital or simplex? Does anyone know of 
any simplex activity there? 


Cap Pennell: 

There's been considerable talk about using 
53.530 for APRS on the national APRS 
email mailing list. 


Gary: 
Isn't that a bit close to 53.52? 


June 17, 1999 

Bob Vallio W6RGG: 

I recommend that 146.595 be listed as 
digital. 


Zonker Harris: 

If 146.52 is National Calling, and channel 
spacing is 20 kHz...then the 146.595 
frequency is off-frequency. 


Bob W6RGG: 

The first "channel" 
146.010; and all channels higher in 
frequency are spaced 15 kHz apart. 
Somewhere down around 145.010, I think, is 
where the 20 kHz spacing starts, but I truly 
don't know where it ends. 


above 146.000 is 


Robert Wilkins N6FRI: 
(Gave some history behind 146.595.) 


(Discussion follows about channel spacing in 
regards to 146.595) 


Steve Grajeda, WB6YQP: 

The Oregon Region Relay Council, Inc 
(ORRC) has been using 10 KHz steps on 
packet radio for about 6 years now. We have 
found it very effective and we use 4 KHz 
deviation max. This way we are able to 
accommodate many more nodes on LAN 


frequencies. 
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NCPA’s Comments to FCC Regarding 1998 Review of Part 97 


The FCC initiated a review of Part 97, WT Docket 98-143. Many amateurs sent in comments, mostly having to do with CW 
testing requirements and how many license classes there should be. The NCPA took the opportunity to comment on another 
section of Part 97 that seemed to be poorly written. Below is the text of that comment. 

At this time, there is no word on the status of the review, nor on whether the FCC is even considering our comment. If 
nothing comes of this, the NCPA will consider submitting to the FCC a similar document for proposed rule-making. If anyone 
has any comments about this, feel free to mention it to any board member or on the NCPA remailer. 


Before the Federal Communications Commission 
Washington, D.C. 20554 


In the Matter of WT Docket No. 98-143 


Amendment of Part 97 of the 


) 
) 
1998 Biennial Regulatory Review ) 
) 
Commission's Amateur Service Rules. ) 


97.303(e) paragraph five is flawed and needs revision; too much authority is given to 
AMTS. 


Currently, Part 97.303(e) paragraph five reads: 
No amateur station may transmit in the 219-220 MHz segment from a location that is 
within 80 km of an AMTS Coast Station unless the amateur station licensee holds 
written approval from that AMTS licensee. 


It appears that the FCC is abdicating its authority here. To our knowledge, there ar 
no other cases where a private license holder has absolute veto power over another user 
or service on frequencies that they may not even share. 


An AMTS station has no incentive to grant permission. And experience has shown that 
they are motivated to deny permission, even if they would not be affected either way. 


The main reason for changing this law is that it currently gives AMTS stations 
authority over the whole band segment, regardless of their usage. An AMTS licensee 
could be on only one channel at the lower end of the 219-220 band, yet still be able 
to deny permission to amateur activity on only one channel at the other end of the 
band! If the channel were shared, an argument could be made for requiring permission 
from the primary channel user (AMTS), but that's not necessarily the case here. An 
AMTS station should not have any say over frequency usage far removed from their 
channel. 


It is highly recommend 97.303 (e) paragraph five be changed to read: 
No amateur station may transmit on the same frequency in the 219-220 MHz segment as 
an AMTS Coast Station from a location that is within 80 km of that AMTS Coast 
Station unless the amateur station licensee holds written approval from that AMTS 
licensee. 


Existing restrictions on RF spilling over into adjacent channels should be adequate. 
However, it would be acceptable to have an added specification that permission might 
be required if the amateur station transmissions are noticed by the AMTS station or if 
more than a certain amount of power from the amateur station appears on the AMTS 
frequency. 


Approved by the NCPA Board of Directors, 


Gary Mitchell, WB6YRU 
NCPA President 


Summer, 1999 Page 15 


Northern California Packet Association 


Northern California Packet Band Plan 
August 1999 


50 MHz 


50.60-50.80 (20 kHz channels, non-specific at this time) 
51.12 SCA backbone 

51.14 BBS 

51.16 Keyboard to Keyboard 

51.18 Experimental 

51.62 Forwarding DX Cluster 

51.64-51.68 (20 kHz channels, non-specific at this time) 


144 MHz 


144.31 BBS 

144.33 Balloon & experimental 

144.35 Keyboard to Keyboard 

144.37 BBS LAN forwarding 

144.39 APRS (U.S. and Canada) 

144.41 duplex, lower half (145.61 upper half, 1.2 MHz split) 
144.43 TCP/IP (OK to run duplex with 145.65) 
144.91 Keyboard to Keyboard 

144.93 BBS 

144.95 DX Cluster 

144.97 BBS 

144.99 BBS 

145.01 User access 

145.03 Keyboard to Keyboard 

145.05 Keyboard to Keyboard 

145.07 BBS 

145.09 BBS 

145.61 duplex, upper half (144.41 lower half) 
145.63 BBS 

145.65 TCP/IP 9600 bps (OK to run duplex with 144.43) 
145.67 DX Cluster 

145.69 BBS 

145.71 9600 bps 

145.73 BBS 

145.75 TCP/IP 

145.77 DX Cluster 

146.58 DX Cluster 


NOTES: 
e Allocations from 144.31 through 144.43 are relatively close to 
the weak-signal sub-band, so watch your deviation. 


220 MHz 


219.05-219.95 100 kHz channels, Backbone 
223.54 LAN 

223.56 LAN 

223.58 LAN, Gilory (GARLIC) 

223.60 LAN, Sacramento Valley (SACVAL) 
223.62 LAN, South Bay (SBAY) 

223.64 TCP/IP 

223.66 Keyboard to Keyboard 
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223.68 DX Cluster Backbone 

223.70 LAN, Monterey Bay & North Coast (MRYBAY) 
223.72 LAN, North Bay (NBAY) 

223.74 Backbone, DX Cluster 


NOTES: 

e¢ 219 channels are by coordination only. There are currently 
political problems with using 219-220. 

¢ On 223.58, TCP/IP interlink (Sacramento) is secondary, not to 
interfere with node uplink. 

¢ 222.14 was recognized as weak signal and the existing DX 

spotting stations moved to 223.68 on March 7, 1999. At 

the same time, 223.68 was changed to DX Backbone. 


440 MHz 


433.15 BBS backbone (by coordination only) 
441.50 Any 


More 70 cm packet channels are currently being investigated, 
possibly 433.x and 438.x MHz. Contact the NCPA for details. 


900 MHz 


903.500 1 MHz wide, TCP/IP 
904.500 1 MHz wide, TCP/IP 
915.500 1 MHz wide, experimental 
916.100 200 kHz wide, experimental 
916.300 200 kHz wide, experimental 
916.500 200 kHz wide, experimental 
916.650 100 kHz wide, experimental 
916.750 100 kHz wide, experimental 
916.810 20 kHz wide, experimental 
916.830 20 kHz wide, experimental 
916.850 20 kHz wide, experimental 
916.870 20 kHz wide, experimental 
916.890 20 kHz wide, experimental 
916.910 20 kHz wide, experimental 
916.930 20 kHz wide, experimental 
916.950 20 kHz wide, experimental 
916.970 20 kHz wide, experimental 
916.990 20 kHz wide, LAN links (Contra Costa County only) 


900 MHz activity is on a non-interference basis to vehicle locator 
service. This sub-band is not considered suitable for 
omnidirectional systems, use for point-to-point links only. 


1296 MHz 
1248.500 1 MHz wide, experimental * 
1249.000-1249.450 Unchannelized, experimental 


1249.500 100 kHz wide, experimental 
1249.600 100 kHz wide, experimental 
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1249.700 100 kHz wide, experimental * 
1249.800 100 kHz wide, experimental’ 
1249.870 20 kHz wide, experimental 
1249.890 20 kHz wide, DX Packet Cluster 
1249.910 20 kHz wide, experimental” 
1249.930 20 kHz wide, experimental” 
1249.950 20 kHz wide, experimental” 
1249.970 20 kHz wide, experimental” 
1249.990 20 kHz wide, experimental” 
1250.500 1 MHz wide, experimental 
1251.500 1 MHz wide, experimental 
1297.000-1298.000 Unchannelized, experimental 
1298.500 1 MHz wide, experimental’ 
1299.000-1299.450 Unchannelized, experimental 
1299.500 100 kHz wide, experimental 
1299.600 100 kHz wide, experimental 
1299.700 100 kHz wide, experimental’ 
1299.800 100 kHz wide, experimental’ 
1299.870 20 kHz wide, North Coast LAN 
1299.890 20 kHz wide, DX Packet Cluster 
1299.910 20 kHz wide, experimental” 
1299.930 20 kHz wide, experimental” 
1299.950 20 kHz wide, experimental” 
1299.970 20 kHz wide, experimental” 
1299.990 20 kHz wide, experimental” 


” Full duplex channel pairs at 50 MHz separation, example: 
1249.970 <> 1299.970 


Definitions 


9600 BPS Stations using 9600 baud with direct FSK (G3RUH, 
TAPR, etc.) modems. 


Backbone No uncoordinated stations. These channels are for 
specific purposes as defined by the NCPA and/or affiliated groups. 
These are frequencies where the various BBS, nodes, and clusters 
forward traffic and are very high volume channels. Please use the 
normal user entry points of the network you want to access rather 
than these channels. 


BBS These frequencies are for user access to a full-service BBS. 
Keyboard-to-keyboard is tolerated. Please don't put high level 
nodes or digipeaters on these channels since they are *local*. A 
low-level direct link or node that links into a backbone on another 
frequency is the proper implementation. 


Duplex Simultaneous transmit and receive by a single station, 
including digital repeaters. Duplex channels are intended for 
high-volume applications. 9600 baud or higher is encouraged, but 
not required at this time. 


DX Cluster Northern California DX packet spotting network. No 
other activity should be on these channels. 


Experimental Anything goes except full service BBS or any 24 
Hr/Day services (nodes, gateways, etc). This is where you can test 
new gear, programs, etc. These channels may be reassigned in the 
near future, so no permanent activities please. 
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Forwarding same as backbone 


Keyboard to Keyboard Anything but full service BBS, TCP/IP, or 
DX Cluster. Primarily chat channels. These are also the primary 
emergency channels. 


Interlink same as backbone 


LAN Local Area Network. BBS's are grouped into LAN's for more 
efficient forwarding. A LAN frequency is the forwarding channel 
within a LAN and to the backbone. Please do not attempt to access 
the BBS network on these channels. 


Personal _mailbox/maildrop A BBS-like system, often running 
entirely within a TNC, with a small number of users that handles 
information of a personal, local or special-purpose nature. A 
mailbox is allowed on keyboard-to-keyboard channels ONLY if it 
does not forward with other BBSs. Mailboxes may forward with 
full-service BBSs on LAN channels at the discretion of the BBS 
SYSOP. 


TCP/AP Stations using TCP/IP protocol on top of AX.25. Some 
AX.25 tolerated to communicate to TCP/IP stations if a compatible 
p-persistence access method used. 


User Access User access to a network. This is for the next 
generation of packet which is expected to operate like the internet. 
Users would access such a network on these frequencies. The load 
on these channels may be rather high, like BBS channels. The 
activity may be any combination of BBS, keyboard, TCP/IP, or 
other modes. 


Procedure for changes 


Send requests for changes to either the frequency coordinator or the 
NCPA board. The frequency coordinator will then present the 
request to the board along with suggested assignments. The NCPA 
board, elected by you, the packet user, makes all assignments. 


Misc. Info. 


Packet tends to splatter if the deviation is set too high. Please keep 
your deviation to less than 5 kHz. 


NCPA currently does not coordinate individual stations, nodes, etc. 
leaving that to the special interest groups. BBS station coordination 
is done by the PSNC in Northern CA. Coordinations of an alternate 
BBS type network including keyboard and TCP/IP in the central 
valley is done by CVDRA. DX spotting is coordinated by DXPSN. 
Some digital is coordinated on auxiliary channels by NARCC. 


The NCPA board conducts most of its meeting activity 
electronically by internet e-mail remailer, ncpa@qth.net. As with 
face-to-face board meetings, interested persons are welcome. 
Subscribe to the remailer by sending e-mail to majordomo@qth.net 
with "subscribe ncpa" as the message. Subscribing to the remailer 
is like attending a continuous NCPA board meeting. 
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The NCPA fosters digital communications modes of amateur radio through education, band planning, and acts as an 
umbrella organization for various packet special interest groups. Your annual dues helps pay for this newsletter and other 
educational materials activities. If you might be interested in getting more involved, please let us know. 


Call: Home BBS: e-mail: 


Address: 


City: Zip + 4: Phone: 


CO New Membership Renewal Change of Address O I’m an ARRL Member 
O One year: $10 O Two Years: $20 Three years: $30 
(make checks payable to NCPA) 


Please indicate your area(s) of interest: 
O BBS SysOp © BBS User O APRS O NET/ROM TCP/IP O High-speed packet 
DX Packet Spotting Network © Keyboard to Keyboard FCC/legal issues O Other: 


NCPA Downlink 

Northern California Packet Association 
PO BOX 61716 

Sunnyvale CA 94088-1761 


First Class 


